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Abstract: 



TV)is paper presents a bug understanding system, called sniffer, which applies inspection meUiods 
lo ,.<.rPrate a dcco understanding of a narrow class of errors. Sniffer is an interactive debuggmg aide. 
it ca;; locate asU identify orror-containing implementations of typical programming cliches, and Jt 
r'-i di'scribc iliom using the terminology employed by expert programmers. 

The dchusdng knowledge in SniiTer is organized as a collection of independent experts wr.icii 
r r-derss' -i specific t-rrors. Eacii expert functions by applying a feature recognition process to the lest 
mnpvm, fthe program under analysis), and to the events which took place during me excciUion of 
th-ir.-r.de No deductive machinc-rv is involved. This recognition is supported by two systems; the 
c'icla' IliKkr which identifies small portions of algorithms from a plan for the code, and die time 
l^'^rlvJch provides arccss to all program stares which occurred during the test program's execution. 

in a typical scenario, t:5C us?r interacts with Sniffer to identify a manageable subset of die test 
nrnui-;nn which seems to contain an error. He ihcn issues a complaint describing Uie expected 
bc>ia-ioi of that legion of the code. The sniffer system then selects and applies the relevant bug 
.->xprri<' and produces a detailed icport about any error which is discovered. This rciiort includes a 
hi"h level summarv of Iha error, an analyNis ol the intended function of the code in terms of its 
component parts, and a description of how the parUcular data values and control paUis involved 
duiing execution led to the manifestation of tlie error observed. 

This paper was originally submitted as a master's thesis to the MIT Department of Electrical 
Engineering and Computer Science, on May 8, 1981. 
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Introduction - 7 - Section 1 

1. Introduction 

This thesis presents a system, called Sniffer , which deeply understands some errors in code. 
Starting from a bug description supplied by the user, the system can trace an error to its source, 
recognize the purpose for the code involved, and describe die problem at a level of detail appropriate 
to an expert programmer. Sniffer identifies errors in programs regardless of their domain of 
application, and it employs mechanisms which are language independent in form. 

The design of Sniffer w^as motivated by the observation tliat debugging is currently an arcane 
science which provides very little guidance for tlie task of identifying errors. The process of 
recognizing bugs requires knowledge from a variety of sources, and typically involves a number of 
different strategies for localizing errors. A pardal list of these sources includes die program, its 
intended purpose, tlie execution paths and data states involved in its execution (either inferred or 
observed), a knowledge of the primidves of die programming language and of the language 
interpretation process, and the mappings between Uie symptoms of bugs and their probable causes. 

In the face of diis diversity. Sniffer employs a generalized production rule format to represent its 
knowledge about bugs. Each expert (or producdon) in die system contains all of the infonnation 
relevant for locadng and idendfying a specific error. This approach defines an inidal dieory of bug 
recognition. It considers errors to be positive entities around which knowledge can be organized, as 
opposed to representing them as differences from an established norm. This mechanism makes it 
possible for individual bug experts to contain extensive knowledge about particular errors. At die 
same dme, die production rule format constitutes a default theory of bug recognition; it is a simple 
mechanism for localizing information which does not reritrict die problem solving methods that can 
be employed. It is also a modular organization in that new bug experts can be introduced with 
comparative ease. 

The expert system methodology is particularly effective in die domain of debugging because it 
cleanly coordinates the process of obtaining information from a number of independent sources of 
knowledge. In a more elaborate theory, uniform methods (such as deduction) should be involved, 
but perhaps as tools, as opposed to the guiding principles of die soUnion. At the current level of 
sophistication. Sniffer shows that an expert system is a natural organization for the task of 
ujidcrstaiiding errors. 

Snirfer is also a cicinonstration of die power of inspection methods in program recognition and 
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analysis. The system generates its understanding of errors by recognizing the pattern of events 
associated witli particular bugs. It identifies algorithms by matching them against progranmiing 
cliches, and it determines the circumstances surrounding errors by directly examining a history of die 
execution of die code. This research shows that inspection techniques are a conceptually simple 
alternative to the creation of deductive engines for discovering facts about code. 

Sniffer is implemented in diree major components; die sniffer system which contains all the 
information relevant for recognizing specific bugs, die dme rover which supports queries about a 
program's history, and the c liche finder , which idendfies fragments of algoridims in programs that 
are used later as a basis for recognizing errors. (See figure 1). 

The debugging knowledge in sniffer is organized as a collection of independent experts for 
specific bugs. Each expert (or sniffer) can examine the user supplied complaint, die suspect piece of 
code, and the execution history of die programi to determine if the bug it knows about is present. The 
sniffers do not contain background knowledge about the pardcular program being examined. Their 
expertise lies in die domain of programming, and concerns typical problems in the use or 
implernentadon of programming cliches. In die current version of Sniffer, each expert idendfies a 
narrowly defined error. The generality of the sniffers come from their ability to recognize 
iniplementadons of typical algorithms independently of die way in which they arc coded. This ability 
is derived from die cliche finder, which in turn is supported by a system, written by Waters [Waters 
1978] that transfonns programs into a regular and language independent reprcsentadon called a 
PLAN (see also [Rich and Shrobe 1976]). The expressive power of PLANs are central to diis thesis. 

The cliche finder is constructed as a collection of procedures which recognize algorithms as 
patterns in die PLAN language representation for programs. The object of the system is to raise the 
level of discourse about a program. Pvaiher than talk about car and cdr operadons, the cliche finder 
makes it possible to speak about aggregates die size of list cnumeradons or splice-in operations. The 
cliche finder operates on die primitive structures of die PLAN language, which include an explicit 
reprcsentadon for die data and control flow within a program, and a taxonomy for the building 
blocks of recursive and iteradve routines. 

TJie dme rover monitors die execution of die test program (the program undergoing analysis) 
and provides access to tlie inforrnaUon it records. It remembers both control infonnadon, and the 
succv'ssion of values acquired by all data objects in die code. At every instance of a side-effect 
operation, the systc:!ii deposits a record which preserves that information. On every function call and 
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Introduction - 10 - Section 1 

function return it deposits an analogous record as well. The result is a complete picture of the 
program's state as it evolves through time. The information in tliis trace is sufficient to rewind the 
program to an earlier point, or to run it backwards if that is desired. In addition, tlie time rover can 
evaluate an expression as if it occurred at an arbitrary moment during die test program's execution. 
Both the user, and die bug experts make use of this facility. 

A general scenario for use of Sniffer is as follows: die user is sitdng at a terminal, watching a 
program run. At some point, he becomes aware that the output is incorrect, aldiough the program is 
still functioning. He stops die execution and investigates the problem using the facilities of die time 
rover. He might examine die order of function calls on die stack, the values of several parameters, or 
events and data in procedures which were invoked and which successfully returned some time ago. 
Eventually, the user finds a particular execution of a region of code which seems to contain a 
problem. He then makes a complaint to the sniffer system, of die logical form 

(get-expert-help expected-resull time-t code-region) 

The sniffer system analyzes the code for expecied-result and for code-region to obtain a quick 
miderstanding of the type of the error. It dien invokes all die relevant bug sniffers. 

A sniffer might look at a die flow of control dirough a specific execution of a nested conditional, 
or compare the values in a list before and after a fimction was called, or ask the user for further 
inform.ation. If the bug the sniffer knows about is present, it produces a detailed error report. This 
report includes a high level summary of the error, an analysis of the intended function of die code in 
tcnns of its component parts, and a description of how die particular data values and control paths 
involved during execution led to the manif:^station of the error observed. 

Sniffer was implemented in Lisp on the MIT Lisp Machine. The Lisp Machine was chosen 
because it has die high speed and large memory capacity required by Sniffer. The programs 
submitted to the system were also written in Lisp. This decision simplified the implementation 
considerations, although it restricted the set of programs which could be analyzed. However, the 
focus of the research remains in language independent techniques. 
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2. A scenario using Sniffer 

ITiis chapter contains a scenario produced by using Sniffer. However, in order to create a 
scenario which shows bug detection, one needs a test program diat is spiked with errors. This 
program has to be complex enough to ilhistrate subtle errors, but also simple enough to avoid 
becoming a distraction from die main part of the research. 

2.1 The test program 

The test program is a morphogenesis simulation, called prospen which loosely models the growth 
of a colony of bacteria. In prosper, tlie user provides an initial pattern of cells and a collection of 
production mles which govern their division. The simulation outputs a trace of the bacteria colony 
through time. 

The cells live on a rectilinear array called die grid. Each cell occupies one square of the grid and 
may have up to four neighbors, corresponding to the top, right, bottom and left positions of the array. 
Every cell has tliree basic properties, a type, an age, and a division time (which is the next time at 
which it is expected to divide). The productions cause cell division. They are local transformations 
that apply to one cell in the context of its immediate neighbors. Productions can access any of the 
properties of the adjacent cells. For example, a typical transfonnation (see figure 2) might map a cell 
of type "c'* surrounded by "a" cells into two "c" units. In order to make the necessary room, tlie 
neighbors are pushed out of tlie way. 

Prosper is implemented as a production rule system tliat operates on data kept in a priority 
queue. This queue, called die events-queue, orders the cells according to dieir division time. The cell 
v/ith the next (or lowest) division-time has die highest priority. (See figure 3 for the top level code.) 
The flow of control is as follows: die grid is initialized with some pattern of cells, and diose cells are 
assigned division times and placed on the events-queue. The central loop removes the first member 
of the queue, and finds die set of productions which can affect cells of that type. One of these 
candidates is selected and applied. 11ie transforms are responsible for requcucing any 
second-generation cells which they produce. /Vo.v/)t^r terminates when the events-queue is empty. 

The grid is implemented as a hash table keyed on the location of cells, (lliis allows incidental 
connectivity to be discovered, when separate formations grow together.) The transfomiations are 
stored in a lil)ra.ry, also in the form of a liasli table keyed on Uic typo of die cell affected. Hie 
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Fig. 2. Some sample transformations 
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Fig. 3. The code for prosper 

(DEFUM PROSPER (EVENTS-QUEUE) 
((LAMBDA (TRAMSFORM-LIB GRID) 
(PROG (MATCHES CELL DIV-TIME) 

(GRtD-INET EVENTS-QUEUE GRID) 
LP (COND ((NULL EVENTS-QUEUE) (RETURN NIL))) 
(DISPLAY-GRID GRID) 
(SETQ CELL (TOP-CELL EVENTS-QUEUE)) 
(SETQ DIV-TIME (TOP-TIME EVENTS-QUEUE)) 
(SETQ EVENTS-QUEUE (REST EVENTS-QUEUE)) 
(SETQ MATCHES (FIND-TRANSFORMS CELL TRANSFORM-LIB)) 
(APPLY-TRANSFORMS MATCHES CELL GRID) 
(GO LP))) 
(CREATE-TRANSFORM-LIB) (CREATE-GRID) ) ) 
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'.enLs-queiic is inipleniciited as a sorted lisL with division-time used as the index. 
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2.2 The scenario 



The following scenario was produced with Sniffer. The dialogue starts after ti\Q program, 
prospen has been running for some time, and has started to generate incorrect output at the terminal. 
The problem is diat the user expected a collection of productions to cause an explosive growdi of 
cancer cells (cells of type "c"), and nothing happened. (The productions are shown in figure 2. 
Figure 4 shows tlic output of prosper.) 



Mg. 4. The output of prosper 
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The user's input is in lower case, and is preceded by a 'X" prompt. System output is in upper 
case. [ liave interspersed comments describing the user's droughts throughout the scenario. 
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1'he user notices that the program is outputting bad data, and interrupts it to find the bug. 

;Breakpoint BREAK; Resume to continue. Abort to quit. 
(Gxamine-h1s tory) 

focus-lime = --26^02, [CDR TRANSFORM]* 

This indicates that the program was intcrniptcil at time --26402, which was at the end of tlie 
excculion oflhe form (CDR TRANSFORM), locus-iifttc is a svslcm maintained glolxjl variable. 
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The user moves the focus of attention to the most recent point in time at which prosper was being 
executed. 

< (move-to (past-when '(in prosper))) 
focus-time = '-26373, GRID* 

This request locates a moment immediately inside of prosper, as opposed to a time within a function 
that prosper calls. 

< (print- frame) 

Execution time: -26373, GRID* 
Function: PROSPER 
Executing at: 

(NAMED-LAMBDi'^ PROSPER (EVENTS-QUEUE) 
((LAMBDA (TRANSFORM-LIB GRID) 
(PROG (MATCHES CELL DIV-TIME) 

(GRID-INIT EVENTS-QUEUE GRID) 
LP (COND ((NULL EVENTS-QUEUE) (RETURN NIL))) 
(DISPLAY-GRID GRID) 
(SETQ CELL (TOP-CELL EVENTS-QUEUE)) 
(SETQ DIV-TIHE (TOP-TIME EVENTS-QUEUE)) 
(SETQ EVENTS-QUEUE (REST EVENTS-QUEUE)) 
(SETQ MATCHES (FIND-TRANSFORMS CELL TRANSFORM-LIB)) 
(APPLY-TRANSFORMS MATCHES CELL GRID*) 
(GO LP))) 
(CREATE -TRANSFORM- LIB) (CREATE-GRID) ) ) 

The flmction print frame displays die context of tlie current execution time. Focus^time is at top 
level during die execution of prosper, at the end of the evaluation of die atom, GRID. After tiiis 
moment, the flow of control enters apply-transforms, and eventually leads to die inteniipted 
execution of (CDR TRANSFORMS). 

Since the problem is that cancer cells are not dividing, the user checks to see if any are scheduled 
for processing. He prints out the contents of die events-queue. 

< (@ focus-time 'events-queue) 

((24 A (-2 0) 2) (24 A (1 0) 2) (24 A (1 1) 2) (24 A (1 -1) 2) ...) 

The function, S, causes a Lisp form to be evaluated in the context of the time supplied as its first 
argument. The events-queue is a represented as an association list of division-times and cells. The 
car of each item is the division time, and the cdr represents a cell 

The user prints out just tlie types of the cells which are in the queue. 
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< (@ focus-time '(mapcar 'cadr events-queue)) 
(A A A A . . .) 

The cells near the top of the events-queue should be cancer cells and tliey are not. However, the 
cell which is currently being processed has already been removed from tlie queue. The user examines 
its value. 

< (@ focus-time 'cell) 
(A (0 -1) 2) 

The user then finds the most recent time when a cancer cell w^as being processed. Its division 
should have instigated explosive growth. 

< (mov8-to (past-when ' ( just-became-true 

'(@ ? '(eq (cell-type cell) 'c))))) 
focus-time - -00720, [TOP-CELL EVENTS-QUEUE]* 

This expression returns the moment when tlie variable, CELL, became a cancer cell. The request 
is implemented by scanning the execution history for tlie moment when the predicate, 
^^""^ (just-became-true . . . ) applies. The variable "?" accesses the scan-time. 

< (print-frame) 

Execution time: -00720, [TOP-CELL EVENTS-QUEUE]* 
Function: PROSPER 
Executing at: 

(NAMED-LAMBDA PROSPER (EVENTS-QUEUE) 
((LAMBDA (TRANSFORM-LIB GRID) 
(PROG (MATCHES CELL DIV-TIME) 

(GRID-INIT EVENTS-QUhUE GRID) 
LP (COND ((MULL EVENTS-QUEUE) (RETURN NIL))) 
(DISPLAY-GRID GRID) 

(SETQ CELL [TOP-CELL EVENTS-QUEUE]*) 
(SCTQ DIV-TIME (TOP-TIME EVENTS-QUEUE)) 
(SETQ EVENTS-QUEUE (REST EVENTS-QUEUE)) 
(SETQ MATCHES (FIND-TRANSFORMS CELL TRANSFORM-LIB)) 
(APPLY-TRANSFORMS MATCHES CELL GRID) 
(GO LP))) 
(CREATE -TRANS FORM- LIB) ( CREATE -GRID) ) ) 

Execution is at the end of (TOP-CELL EVENTS-QUEUF ) Just before tlic setq function returned. 
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< (Q focus-time ' eel 1 ) 
(C (0 0) 1) 

T'liis cell should have mclastasized, and yet it did not. Rie next expression looks f )rwcird to a 
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time when tlic transformations which could apply to CELL have been selected, and evaluates MATCHES 
in that environment. 

< (@ (future-when '(eq (current-function ?) * apply-transforms) ) 

'matches) 
((OLD~AGED-CELL DIE) (CANCER-CELL-WITH-ONE-NEIGHBOR METASTASIZE)) 

MATCHES is a list of two transformations. Each trans fomiation has two parts, a predicate which 
determines whether the production can apply, and a ftmction which implements tlie transformation 
itself. The first candidate in MATCHES removes old-aged cells from the grid, tlie second 
transfomiation causes explosive growth. The user detemiines which one was selected. 

< (@ focus-time ' (old-agGd-cel 1 cell grid)) 
NIL 

This expression reevaluates the predicate for tlie "die" transformation in the current 

time- environment. The result is necessarily identical to the one returned by the original invocation of 

that form in the test program. Since it is NIL, the metastasize function must have been selected 

f^^^ instead. The user moves forward in time to a moment wljcn top level code in "metastasize" is being 

evaluated. 

< {move-to (future-when '(in metastasize))) 
focus- time = -01751, 

^[NAMED-LAMBDA METASTASIZE (RIGHT-CELL KEY-CELL) .,.] 

< (print-frame) 

Execution time: -01751, 

*[NAMED- LAMBDA METASTASIZE (RIGHT-CELL KEY-CELL) ...] 
Function: METASTASIZE 
Executing at: 

*[NAMED-LAMBDA METASTASIZE (RIGHT-CELL KEY-CELL) 
((LAMBDA (rJEW-CELL LOCATION) 

(INCREHEfJT-DIVISION-COUWT KEY-CELL) 
(MAKE~RDOfv!-BETWEi:i^ KEY-CELL RIGHT-CELL GRID) 
(GRXD-iliSERT r^EH'-CELL LOCATION GRID) 

( EVENTS-QUEUE- IflSERT NEW-CELL (+ DIV-TIME 2) EVENTS-QUEUE) 
(EVEMTS-QUEUE-irJSERT KEY-CELL (+ DIV-TIME 2) EVEMTS-QUEUE)) 
(CREATE-CAMCER-CELL) (CELL-LOCATIOW RIGHT-CELL))] 

The calls on cvcnts-queue-inscrt should have placed the cancer cells, ncw-ccll and key-cell, on 
the evenrs-qucue with a high priority division time. The user checks to sec if the events-queue was 
modified at any time during tlie execution of that procedure. 
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< (move-to (f uture-v^hen ' (eq (current-function ?) 

'events-queue- insert))) 
focus-time = -02672, 

*[EVENTS-QUEUE-INSERT WEVI-CELL (+ DIV-TIME 2) EVENTS-QUEUE] 

< (unmodified* (@ focus-time 'events-queue) 

(@ (end focus-time) 'events-queue)) 
T 

In an environment where different versions of an object can be compared across time, several 
new types of equality become important. Unmodified* is the strongest test possible. (See the section 
on equality and coreference for a detailed discussion.) The expression (end focus-time) returns 
tlie time corresponding to the end of tlie evaluation of the current function. 

The results of the test confirms the user's suspicions. The insert function was called, but the data 
never entered the events-queue. This is a suitable point to ask tlie sniffer system for its opinion. 

< (get-expert-help '(events-queue-member new-cell events-queue) 
focus-time 
(end focus-time)) 

The get-expert-help function invokes die sniffers. The first argument is a Lisp predicate that is 
expected to apply (to be non-nil) after the execution of the region of code specified by the last two 
arguments has occurred. In this case, that rcgiori happens to enclose a single s-expression (the call on 
events-queue-insert). The sniffers use the predicate as a partial specification for the code in the 
region. They examine tlie code for the predicate, and the code inside the region, as well as the 
control flow and data values involved during those sections of execution. The sniffer which 
identified the bug produced die following report. 
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Bug Siunmary 

The bug is a case of violated expectations. The function METASTASIZE 
called EVENTS-QUEUE-INSERT v/ith the apparent intent of inserting 
NEW-CELL into the EVENTS-QUEUE by side-effect. The insertion did not 
occur because EVENTS-QUEUE-INSERT is an insertion function for sorted 
lists without header cells. It does not act by side-effect when the 
item sorts to the beginning of the queue. It conses it onto the top 
of the 1 ist instead . 

Analysis 

The function 

(DEFUN EVENTS-QUEUE-INSERT (ITEM TIME EVQ) 
(PROG (NEW OLD ENTRY) 

(SETQ ENTRY (CONS TIME ITEM)) 

(COND ((OR (NULL EVQ) (BEFORE? ENTRY (CAR EVQ))) 

(RETURN (CONS ENTRY EVQ)))) 
(SETQ NEW (CDR EVQ)) 
(SETQ OLD EVQ) 
LP (COND ((OR (NULL NEW) (BEFORE? ENTRY (CAR NEW))) 
(RPLACD OLD (CONS ENTRY NEW)) 
(RETURN EVQ))) 
(SETQ OLD NEW) 
/**^s (SETQ NEW (CDR NEW)) 

(GO LP))) 

is recognized as a non-header-cel 1 insertion function for sorted 
lists. In this execution, the item to be inserted was (12 C (-1 0) 1) 
and the value of EVQ was 

((24 A (0 1) 2) (24 A (0 -1) 2) (24 A (-2 0) 2) (24 A (1 0) 2) ...) 

The ordering test, (BEFORE? ENTRY (CAR EVQ)) sorted the item to the 
top of the list, and therefore tho splice-in did not occur. 
EVENTS-QUEUE-INSERT returned (CONS ENTRY EVQ) which evaluated to 

((12 C (-1 0) 1) (24 A (0 1) 2) (24 A (0 -1) 2) (24 A (-2 0) 2) ...) 

The function 

(DEFUN METASTASIZE (RIGHF-CELL KEY-CELL) 
((LAMBDA (NEW-CELL LOCATION) 

(INCREMENT -DIVISION-COUNT KEY-CELL) 
(MAKE-ROOM-BETWEEN KEY-CELL RIGHT-CELL GRID) 
(GRID-INSERT NEW-CELL LOCATION GRID) 

*[EVENTS-QUFUE-I!JSERT riEW-CELL (+ DIV-TIME Z) EVENTS-QUEUE]* 
(EVENTS-QUEUE-INSERT KEY-CELL (4- DIV-TIME 2) EVENTS-QUEUE)) 
(CREATE-CANCFR-CELL) (CELL-LOCATION RIGHT-CELL))) 

ignores the value returned by EVENTS-QUEUE-INSERT on the indicated 
call, and consequently the results of the insertion were forgotten. 
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1 The Time Rover 

The purpose of the time roving facility is to allow the user, and the bug experts, to query the 
execution history of die program undergoing analysis. The system was designed to support the style 
of investigation displayed in the scenario. In order to do tliis, the time rover maintains a complete 
trace of the events which occurred during execution, and allows arbitrary Lisp expressions to be 
evaluated as if particular program states were in effect. 

The best way to explain tlie issues involved in time roving is to discuss its implementation. This 
is not intended as an overture to the inclusion of excessive detail. Since Sniffer was v/ritten to 
demonstrate a point rather than as a system utility, it was implemented with a conceptually simple 
design. Efficiency was not a concern. 

3.1 Tcrmmologj' 

The exec ution history of a program refers to the sum total of events Vvhich occurred while it was 
running; the flow of control, the sequence of side effect operations, etc. The execu tion trace refers to 
the physical structures which are used to represent tliat history. 

Within an execution history there are various named times, or moments. Time can ordinarily be 
thought of as an integer. It starts at 1 and increases monotonically as execution progresses. The 
beginning and tlie end refer to the first and tlie last moments during the execution of tlie user's 
program. Focus-time corresponds to a specific moment in the execution trace. It is the focus of 
attention within the history. 

There is also a convention for naming directions. Earlier moments are closer to the beginning 
and later moments are nearer the end. Figure 5 illustrates these ideas. A ti me-enviro nment is an 
abstract object in which one can look up the bindings of variables and their properties, etc., which are 
in effect at a given dme. For lack of a better method, all moments will be referred to in the present 
tense. 
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3.2 Implementation 

The time rover is composed of two parts, called the keeper and the seen both of which are 
constructed as modified evaluators for Lisp. The keeper is used (primarily) to generate a history for 
the test program. It can be thought of as a careful evaluator which deposits records as it executes 
forms. The seer listens to the user's debugging requests. It has die ability to investigate and compare 
any of the states associated with the test program's history. 

In the scenario, the keeper processed the original execution of prosper, and all forms typed by 
die user were handled by the seer. The special function, §/ invoked a second usage of the keeper; it 
caused die keeper to evaluate an expression in die context of a specified time. (In some sense, the 
biggest distinction between the keeper and the seer is diat the keeper can only think about one 
moment at a time, vvliile the seer knov/s about all times at one moment.) 
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3.3 The keeper 

Tlic keeper unplements a restricted version of Lisp, called K-liso , which is different from normal 
Lisp in two ways: it considers code to be an immutable object, and it uses the execution trace as the 
environment for containing K-lisp objects. This includes "heap" data and variable binding 
information. The execution trace is a staicture which totally orders control flow events, and 
side-effects events (changes in the contents of memory cells) with time. Conceptually this 
information is divided into two parts, the control flow history , and the incarnation series . 

Tlie control flow history records all calls and all returns from tlie evaluator. It is a 
straightforward extension of the Lisp stack, where no information is forgotten. Every call moment 
contains a link to the invocation time of its parent, and every return moment contains a link to its 
matching caller, (See figure 6.) This history contains more infonnation than is necessary to record 
the control flow unambiguously (only tlic choices taken at branch points are strictly required), but it 
was more convenient for my purposes to have the data in tliis form. 



Fig, 6. A control flow history 
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The incarnation series is a time ordered sequence for the vahics which each memory cell acquires 
during the execution of the test program. This information is stored in terms of [name, binding] 
pairs, called trace-cells . A trace-cell is an immutable object that records the contents of a cons (or the 
value of an atom) at a particular time. The name component of a trace-cell is analogous to the 
address of a cons in Lisp. It provides a handle on all of the versions of a given cell. The binding field 
of a trace-cell contains a car-part and a cdr-part which represent the car and cdr of the corresponding 
Lisp cons. Trace-cells are invisible to the programmer. 

In the keeper, a value is a name. The data associated with a given narne {id or cell- id) at a given 
time is found by scanning the incarnation series for the most recent trace-cell with die appropriate id. 
This search fulfills a role which is exactly analogous to looking up an address in noiTtial Lisp. During 
the evaluation of the test program, the current execution time is used as the starting point for 
scanning die incarnation series. During debugging, Uiat time is supplied by the seer. 

The primitive operations of K-lisp are modified to accommodate trace-cells. The functions 
which produce side effects cause trace-cells to be deposited, and the information obtaining 
operations, car, cdn and symeval are modified to access these staictures via search. (I will discuss the 
new versions of eq and equal in a later section.) For example (see figure ^), the function cons in the 
statement 

(cons *a *b) 

produces the trace-eel! [cons-24, a.b], which indicates Uiat the binding associated with the cell-id, 
cons- 24 represents the (traditional) cons of the atoms a and b. (The cons function is a side-effect 
operation in the sense that it allocates storage wliere none was required before.) Trace-cells, like 
conses, contain tlie values of Lisp objects. The statement 

(cons a b) 

would produce a different trace cell, who's car-part was the value of a and who's cdr-part was die 
vahie of b. The funciions rplaca and rplacd create similar trace cells, except that the name field 
contains the id of the cell which is being updated. The nmction setq in tlie statement 

(setq h 3) 

results in a trace- cell who's name is the atom, //, and who's binding field has a car-part containing the 
number 3. Only mutable objects need to have Irace-ccHs to record the sequence of their values. 
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Numbers and similar constants can appear in the binding parts of trace-cells, but not in name fields. 

The operations car, cdr, and synteva! each map a cell-id into another cell-id. The car of a cell-id is 
the car-pan of the corresponding trace-cell (the one in effect at the current time). Similarly, die cdr 
of a cell-id is the cdr-pari of the associated trace-cell. All of these functions involve an identical 
search through die incarnation scries. For example, the function symeval takes in an id (which must 
be an atom name), scans die incarnation series for die most recent trace-cell widi that id in die name 
field, and outputs the car-part of the trace-cell which is discovered. 



3.3.1 An example of the evaluation process 



Figure 8 shows a collection of snapshots of the incarnation scries as the rt)llowing statements are 
executed. 
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(setq y (cons 1 nil )) 
(setq z (cons 2 y)) 
(rplaca (cdr z) 3) 

The first event is the creation of the trace-cell for (cons 1 nil ). The name field is arbitrarily set 
to celrl, and the trace-cell is deposited at time 1. Tlic setq operation deposits a trace-cell Vvdth tlie 
nam.e field y, and a binding field who's car-part is the cell-id, ccll-l. No pointers are involved. 
Similarly, in the trace-cell which is deposited by (cons 2 y), the value of y is represented by cell-I 
again. This process continues until (rplaca (cdr z) 3) is evaluated. In normal Lisp, this side-effect 
would have changed the contents of an existing cell. In the keeper, a new trace-cell is deposited with 
the same name field, cell-l. 

In order to evaluate Lisp expressions, the keeper has to find the appropriate trace-cell every time 
a cell-id is referenced (there may be many with the same name). For example, in figure 8, the value 
of y at time-2 is found from trace-cell #2 to be the cell-id, cell-I. To print out the value of y, liie 
binding of cell-I at time-2 has to be printed. In tliis case, the contents of trace-cell #1 are the correct 
result. The list "(1)'* is printed. 

In order to evaluate the predicate (@ time -5 '(car y)) the keeper has to discover that y was 
changed by an indirect side effect through z. This process is accomplished as follows. Starting from 
time-5, the keeper looks for the most recent setq record for die atom y. The value of y turns out to be 
die id, cell-I, which was discovered from the trace-cell deposited at timc-2. Next, the keeper takes the 
car of cell-I, in the context of time- 5. It scans backw^ards from time-5, looking for the most recent 
version of cell-I and returns the car-part of tlie resulting trace-cell. Trace-cell #5 has the appropriate 
name, and riie number "3" is returned. 

In order to print out the elements of a list in the context of a given time, die keeper has to 
interpret each of the cell-ids involved. For example, the value of z at both time-4 and time-5 is celI-2, 
but the list it represents at time-4 is composed of trace-cells #3 and #1 (the list "(2 1)"). At time-5, 
z is built from trace-cells #3 and #5, corresponding to the list "(2 3)'\ 
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Fig, 8. The development of the incarnation series during execution 
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33.2 Effeciency considerations 

The time rover was implemented with a list like representation for its environment in order to 
make the system easy to code. Once it was implemented, I discovered that it was slow, but not quite 
so slow as expected. For simple requests, die keeper responded almost as quickly as die normal Lisp 
interpreter. However, the time requirement for each reference unfortunately increases with the size 
of die execution trace. At the end of the scenario, die dme rover required approximately half of a 
second to locate each cell-id. 

The searches involved in mnning the test program can be entirely eliminated by introducing a 
new data stmcture, called the now-arra v, to maintain the end time- environment. (This environment 
is the one nonnally associated with a mnning program, it always holds the state of die latest moment 
of execution.) This table would contain a mapping of cell-ids to their current bindings. In different 
words, tlie now-array would be a shallow binding of cell-ids to car~paru cdr-part pairs from 
trace-cells. Since cell-ids can be chosen freely, they can be set up as indices into successive memory 
locations of the now-array. This would essenUally eliminate all searches for cell-ids (at a factor of two 
ovcrliead in space). 

The now-array would not speed up die execution of debugging requests. These requests 
typically access a number of dme-environments in rapid succession, which suggests diat a search 
paradigm is more reasonable dian the alternative of updating the now-array to contain die 
Ume-environment o^ focus- lime, "^'hcnoYor focus- lime changes. 

A second improvement would be to move to a non-linear reprcsentadon for die execution trace. 
Since the critical issue is to find cell^ds as fast as possible, a hashing sclieme on celt names is a 
possibility. I did not employ this approach because diere was some subdety involved in integrating it 
with the need to represent alternate evaluation sequences (see below). 

In any case, the mem.ory requirement for the keeper grows with the duradon of execudon. At 
some point, diis will threaten to exceed the capacity of any machine, in which case it would be 
possible to "forget" about certain portions of the execudon history. These regions would then 
become opaque to the dme rover. h\ mnning tJic scenario, no memory capacity problems were 
encountered. 
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3.4 The seer 

The function of the seer is to provide the user with a uniform mechanism for operating on data 
from the execution trace, and for manipulating tlie objects defined in his own local debugging 
en\dronment. The seer is constaicted as an evaluator for Lisp that is extended to contain 
time-stamped ol)jects, called tpairs, which refer to data from the incarnation series. 

A t-pair contains two parts, a reference time and a cell-id where the reference time specifies the 
time-environment to use for interpreting tlie cell name. Reference times are sticky, in the sense that 
the car of a t-pair is another t-pair with the same reference part. This approach allows die user to 
change tlie perspective used to view an entire I Jsp object by altering the reference time attached to its 
topmxost cell-id. A t-pair is represented here as a bracketed pair of tlie form {time id}. 

The primitive operations of the seer are modified to accommodate this new data type. If a 
primitive is cahed on a normal Lisp object, tlicn it is evaluated in the normal way (this might yield a 
t-pair). When a primitive is applied to a t-pair, it is evaluated with the aid of the corresponding 
operation of die keeper. For example, from figure 8, symeval of {timc-4 z] is tlie t-pair 
{time-4 celL2} where cell-2 was obtained by applying die keeper's symeval function to z at time-4. 

The fimction "0" (which invokes tlie keeper's evaluator on a Lisp form) can be used to state the 
effect of tliese primitives in a more concise form. 

(symeval {t id}) => (@ t '(symeval id)) 
(car {t id}) => (§ t '(car id)) 
(cdr {t id}) => (§ t '(cdr id)) 

(§ returns a t-pair who's reference time is the time supplied by its first argument. 

3.4.1 Alternate time-tracks 

It is not immediately clear how to interpret the application of a side effecting primitive to a 
time-stamped object. The issue is that a t-pair refers to an object from the history of the test program 
v^hich was never subjected to the side effect that the user is requesting. (Information obtaining 
operations arc benign in this sense. They have no potential for altering the data in the trace.) [f the 
execution trace is intended to record the actual history of the program, the question is how can side 
effccts created by the debuggcj- be lactored in? 

'Ilicre are many very confusing ways to resolve tlii^: question. If the debugging session is 
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considered to occur after tlie test program is executed then a side-effect to a variable, say at time- 10, 
would cictually occur at a moment which is later than any moment in tlie execution history. This 
implies tliat a debugging request which accesses the supposedly side-effected data at time- 11 tlnds 
that nothing has changed. 

The approach I take is to interpret all debugging requests tliat access tlie history of the code as 
explorations into alternate time-tracks for tlic test program's development. These debugging requests 
are processed as if the test program executed them at the specified time. For example, in the context 
of figure 8, the effect of the statement 

(Q time-4 '(rplacd (cdr z) 1)) 

is to grow a branch off of the incarnation series at time-4 (fomiing an incarnation tree) and to deposit 
a trace-cell for celhl at that time, fhe side effects created by the flmctions setq, cons, and rplaca are 
handled in a similar way. (See figure 9.) 

This approach implies a small redefinition of die fimction "@". I have described @ as a utihty for 
invoking \h^ evaluator of the keeper. To be more specific, @, in the stcitement 

(f9 time 'expression) 

instmcts the keeper to form a branch in the incarnation tree, and tlien hands the expression to die 
keeper to be evaluated in the context of die time-environment defined by time, (The seer evaluates 
the parameters to @.) @ returns a t-pair which packages together the cell-id returned by the keeper 
and the dme at which the keeper finishes its evaluation. A time can be interpreted as a pointer into 
die incarnation tree, which bi-directionally links trace-cells. 

The seer can use die fimction % to retrieve information from the environment of the keeper, but 
the keeper cannot access data defined in die seer. This occasionally causes some confusion. For 
example, the following expressions (in the seer) 

(setq D ' (a b c)) 

(@ time~2 '(setq y D)) 

will result in an error when the keeper attempts to symeval D at dmc-2, assuming that D is not defined 
in the context of die test program at dial time. (The keeper docs have limited access to the seer, in 
that it can run functions which the user defines in the course of debugging. These functions, must be 
Z***^ ninnablc in K-lisp. They may not reference t-pairs.) 

The definilion of (:^ makes it possible to express the action of die seers primitives on t-pairs by 
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Z"*^- Fig. 9. Vn example of an alternate time-track 

This figiiio shows Llie growth of a brancli in the execution histoiy in response to the code statement 
shown. 
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the following rewriting rules. 

(symeval {time id}) => (@ time '(symeval id)) 
(car {time id}) => (@ time '(car id)) 
(cdr {time id}) => (@ time '(cdr id)) 
(setq {time id} x) => (§ time '(setq id x)) 
(rplaca {time id} x) => (§ time '(rplaca id x)) 
(rplacd {time id} x) => (@ time '(rplacd id x)) 

The information obtaining operations create degenerate branches of the incarnation scries (the time 
does not increase), and the side effecting operations augment the data in the trace. Note that the 
cons of two t"pairs within the seer is not implemented in terms of tlie keeper's primitives. The 
statement 

(cons (0 time-4 'z)((§ time-2 'y)) 
simply creates a cons cell in tlie environment of the seer which contains tlie resulting t-pairs. 



3.^.2 Equality md coreference 

Ihe concepts of equality and coreference have to be extended to fit an environment where many 
versions of data cells are available simultaneously. In normal Lisp, there are only tv^'O ways to 
compare objects. One can ask if they are eq, meaning that diey have the same namic or address 
(which is equivalent to asking if they are coreferent), or if tliey are equal, meaning that tliey contain 
isomorphic data stmctures. 

In the seer, more distinctions are available. One can ask if tv/o t-pairs refer to the same object in 
the keeper (I call this test unmodified), or if two cell-ids are die same (eg). These questions arise when 
objects are compared across times. For example (see figure 8), 

(eq (@ time~2 'y) (@ time-5 'y)) 

is true. Here, tlie list contained in y is different at the two times altliough tlie top level cell-id which is 
tlie value of y is cell-l in both cases, (y contains ( 1 ) at tirne-2 and ( 3 ) at timc-5.) The statement 



1. This is not strictl}' true. Since the stiucturcs rcprc?;cnling the conliol Oow history are merged into the execution trace, the 
^^^\ time docs change on every call to ihe keeper, 1 lowcver, for the purjiose of the prinnlive operations, it docs not change in any 

interesting way. 
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(unmodified (9 time-2 ^y) (Q time-5 'y)) 

is false. This test shows that the value of y was changed between the two times. 

When these predicates are extended to lists, one can ask if two lists contain the same cell-ids at 
every level (called eq*), or if tliey involve tlie same trace-cells at every node (unmodified*). 
Unmodified* is the coreference test in the time roving environment. Eq* is a weaker function. For 
example, suppose that an identical copy of tlie variable y is created by executing the statement 

(0 time--4 '(rplaca (cdr z) 1)) 
(see figure 9). This deposits a record for cell- 1 in a side branch at time-6. In this case, the expression 

(eq* (0 tiiTie-6 'z) (@ time-4 'z)) 
is tme, but 

(unmodified* (§ time-6 ' z) (§ time-4 'z)) 

is false. 

Note that two lists are not necessarily identical if their top level trace-cells are die same. There is 
always the possibility that some internal cell has changed across the two times. From figure 9, 

(unmodified (Q time-5 'z) (@ t1mo-4 'z)) 

is true (z evaluates to celh2 m both cases), but 

(unmodified* (§ time-5 'z) (9 time-4 'z)) 

is false. (Cell-I was updated between tlie tv/o times.) 

The function equal remains essentially linchangcd in the context of the seer. It still tests for 
isomoiphism of structure. There is no requii'emeiU that tlie lists share the sam.e trace-cells or even 
that the same cell-ids are involved. The atoms at the leaf nodes of die tree muist be identical. 

Tlie relationship between diese functions is summarized in figui'e 10. 
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Fig. 10. The hcirarchy of equality tests 

The equality tests for lists represented in trace structures are stronger dian the analogous tests on 
cell-ids; eq* implies ('<? and unmodified* implies unmodified. The converse is not true. Unmodified* 
implies cq*. because lists with the same trace-cells must contain ihc same cell-ids. Eq* implies equal 
because lists built with corresponding cell-ids must match at dhe level of atoms. 
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The keeper and tlic seer define a mechanism that allows die user to execute and then examine the 
history of a test program. The keeper creates the execution history, and evaluates any requests 
submitted by die seer which access diat data. The seer provides die user with a Lisp environment for 
executing debugging requests. It answers questions about die execution history by employing die 
facilities of die keeper. Figure 11 shows die relationship between diese systems. 

The overall environment which the system presents has the user's debugging requests occurring 
in a kind of a super-time which is not ordered with respect to the execution history. From die user's 
perspective, all of the information in the trace is equally accessible. 

I'hc use of alternate time tracks makes it possible to move to moments in die test program's past 
and evaluate arbitrary IJsp expressions in du)sc contexts. The user can define functions, and execute 
them in any time-environment, or explore hypotheses about the test program's behavior by 
rc-cxecuting portions of die code on modified data. The alternate histories which diesc actions create 
can ihemsclves be investigated in the same manner. 
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The functions of the keeper and die seer could conceivably be combined into a single evaluator 
that would have an extra degree of freedom, namely time. In this system, called the time-probe, it 
would be possible to wiite programs tliat routinely call procedures which will be defined in the future 
to modify data which was current at some time in the distant past. The difference between the time 
rover and tliis hypotlietical system is that the time-probe can travel in its own history. Neither the 
seer nor the keeper has this ability (and it is not clear that they require it). 

The Creadon of the dme-probe is left for future research. 

3.6 Methods for spcclfymg times 

The primitives for locating times are cast in the fram.ework of search through the incarnation 
series. There is a nodon of the focus of attention, called the focus- lime, which can be moved 
tliroughout die execution history. The searches for other moments move either forward or 
backwards from that dme. 

Time is a data type recognized by the seer. There are two fimctions which yield dmes; 
futurc-when and past-when. The syntax is 

(future when j^rm) 
where /.V7/2 is an arbitrary predicate evaluated by the seer (it may contain calls on @ which invoke the 
keeper). The function future-when scans forward in time from focus-time and returns die first 
moment when form yields a non-nil (and non-error) result. Past-when performis die analogous 
fimction for moving towards earlier moments in die history. 

The implementadon for these flmcdons is fairly intricate. It would be prohibitive to attempt to 
apply form at every moment in the histor> which is scanned, so the search functions first compute die 
reference set of cell-ids accessed hy form, and then move attention to die nearest moment when one 
of those cell-ids has a different binding. At the rcsuUing time, fonn is reevaluated and die reference 
set computed once again. The process repeats until yc?rm returns a non-nil value (success), or undl the 
search passes beyond the boundaries of the incarnation series (failure). 

The search mechanism is also capable of detecting transitions in the values of form. For example, 
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the expression from tlie scenario, 

(move -to (past -when * (just- became- true 

•(0 ? '(eq (cell type cell) 'c))))) 

caused die form 

(0 ? '(eq (cell-type coll) 'c)) 

to be apphed at the moment discovered by the scan, and die immediately preceding moment. The 
function, just-became-true, identifies a particular kind of transition in the value of its form. Since 
a scan can cause expressions to be applied in time-environments where diey yield errors, 
just "be came- true looks for a transition from either a nil or error result, to a non-nil value. The 
implementation of sniffer contains a number of similar functions; error-to-true, 
error- to -false, false-to-true, etc., as well as two special functions, 
just-about~to-become-true and just-about-to-become-false which return the moment 
immediately before a transition is going to occur. (All transitions are defined to start at earlier times 
/i«"»N. and finish at later ones. The transition functions are not sensidve to die direction of search.) 

The search functions can also em.ploy predicates which depend upon data in the control flow 
history. For example, the expression 

(future-when '(during metastasize)) 

(not shown in die scenario) returns die next dme when execudon is within the definition of 
metastasize. Since the records in die control flow history provide die code associated with each call 
and return from die evaluator, detecdng during- nes^ is not very hard. The procedure ascends the 
parent hierarchy of funcUon calls to see if It locates die expression which is die definidon of 
metastasize. 

It tin*ns out that the interacdon between diese kinds of requests and the search mechanism is 
somewhat tricky, hi order for the search functions to know when next to apply a form, each 
predicate on control flow has to idenufy the borders of its current truth value. In some cases diis is 
easy; during knows that it ceases to apply at the endpoinls of its span (which are trivially available 
from the cxccuUon trace). However, if during does not apply at the current moment, it has to find 
the bordering tiincs where it does. This partially subverts ihc purpose oi the scan mechanism, which 
/****"■> was .^tempting to find those moments to begin with. Some more sopViisticated approach may be 

called for. 
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4, Th€ cliche finder 

The cliche finder perfomis two fi^mctions within Sniffer; it recognizes small algorithms from the 
test program in order to provide the bug experts with a context for identifying errors, and second, by 
identifying algoritlinis, it raises the level of the vocabulary which the system can use to describe code. 

For example, in order to identify the error described in the bug report (see page 18), tlie cliche 
finder recognized that events-queue- insert implements a particular kind of list insertion (a 
non-header-ceil insertion for sorted lists). It also identified cliches which were components of that 
insertion, namely a splice-in operation, an ordering predicate test and a list enumeration, some of 
which it referred to by name in the bug report. 

The cliche finder is composed of a collection of algorithm detectors which operate on an 
alternate representation for programs, called a PLAN. PLANs (developed by Waters, Rich and 
Shrobe [Waters 1978] [Rich and Shrobe 1976J) are a powerful tool for supporting program 
recognition because tliey are a language independent notation, and they represent small algorithms in 
an essentially canonic form. The geneiality of the cliche finders depends upon these properties of 
PLANS. 

41 An overview of PLANs 

PLANs identify several critical constraints on the representations of algorithms. (See 
[Waters 1978] for a detailed discussion.) I summarize the m.ain points below. 

PLANs ignore the way in which control and dataflow is implemented. For example, it makes no 
difference if the control stmcture for a program uses conditionals or goto statements, both map into 
the same PLAN. Similarly, all the possible mcdiods of using variables to hold partial results or 
propagate values are judged equivalent. PLANs are based on data flow; they extract only the 
essential interconnections between operations that produce and consume data in code. 

PLANs associate related segments of code which may have been widely separated in the original 
text. A PLAN is a compound object composed of data flow related segments. The fiict that one piece 
of code outputs data which another consumes is a simple proof tliat both are working towards some 
unified goal, llie consequence of this organization is that feature detection in PLAN space involves 
far less search than it would require in the original text for the code. 
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The PLAN representation is partitioned into fragments which have stereotyped behaviors. This 
allows complex programs to be understood in tenns of simple purposeful parts. For excimple, 
iterative and recursive routines are represented by a single PLAN structure (a PLAN Building 
Method, or PBM in Waters' temiinology) called a temporal composition which can contain five types 
of components; initializations, generators, filters, accumulators and tenninators. (The output of his 
analysis system labels the segments which fulfill each of tlie five roles.) An initialization is a segment 
tliat is executed once before a loop is entered. A generator produces a sequence of values that are 
used in later calculations (a list enumerator is an example of a generator). Filters restrict the 
sequence of values which are available beyond their location in the code. Accumulators perform 
calculations, they remember results Terminators are like filters in diat they restrict sequences of 
values, however, they may also stop die execution of a loop. The remaining plan building methods 
categorize tlie program actions in straight line code. Taken together, tlie PBMs provide a complete 
parse of a program into these puri30seful parts. (The mechanisms which perform this analysis are too 
lengthy to describe here. See [Waters 1978] for a full explanation.) 
^*^ The result of features described above is that many textual rcpresentadons for the same 

algorithm are m.apped into identical (or nearly identical) PLANs. For example, if the function, 
events-queue -insert, is implemented using eitlier of the expressions in figure 12, it analyzes into 
the exact same PLAN, lliis is taie even diough die fonns involve different control structures, 
different variable names, and distinct Lisp primitives. 

4.2 An example of cliche recognition 

The algoriUim recognizers identify procedures by matching their PLANs against known cliches, 
l^his match must be essentially exact. (The cliche finders can tolerate variations at die level of 
ignoring extraneous detail) For algorithms of complexity of events-queue-- insert this approach 
has been successful. The recognition of larger programs will require more sophisticated methods. (I 
discuss some alternative approaches in the section entitled extensions.) 

The following tliree figures present the PLAN for events-queue- insert in its entirety. These 
diagrams explicidy represent a considerable amount of information which is hidden in code, and they 
contain some special notation as well. However, most of the detail can be safely ignored. The figures 
are presented in order to iriotivate specific examples which draw on portiiins ofllie PLANs. 



/*% 



Notation - 38 - Section 4.2.1 

Fig. 12. List insertion programs which map into the same PLAN 

(DEFUN irfSERT (DATUM KEY QUEUE) 
(LET ((OBJECT (CONS KEY DATUM))) 

(COMD ((OR (NULL QUEUE) (BEFORE? OBJECT (CAR QUEUE))) 
(CONS OBJECT QUEUE)) 
((DO ((NQ (CDR QUEUE) (CDR NQ)) 
(OQ QUEUE NQ)) 
((OR (NULL NQ) (BEFORE? OBJECT (CAR NQ))) 
(RPLACD OQ (CONS OBJECT NQ)))))))) 

-[b]- 

(DEFUN EVENTS-QUEUE-INSERT (ITEM TIME EVQ) 
(PROG (NEW OLD ENTRY) 

(SETQ ENTRY (CONS TIME ITEM)) 

(COND ((OR (NULL EVQ) (BEFORE? ENTRY (CAR EVQ))) 

(RETURN (CONS ENTRY EVQ)))) 
(SETQ NEW (CDR EVQ)) 
(SETQ OLD EVQ) 
LP (COND ((OR (NULL NEW) (BEFORE? ENTRY (CAR NEW))) 
(RPLACD OLD (CONS ENTRY NEW)) 
(RETURN EVQ))) 
(SETQ OLD NEW) 
(SETQ NEW (CDR NEW)) 
(GO LP))) 



/^ 



4.2,1 Notation 

PLAN diagrams contain three kinds of entities; boxes, solid lines and, dashed lines. Boxes 
represent actions which may be either primitive or compound. A primitive action corresponds to a 
black box in tlie code, such as a cons statement in Lisp. There are eleven types of compound actions, 
these include conjunctions, predicates, and conditionals for representing straight line code, and Jilters, 
accumulations and tenninations for representing looping behavior. Dashed ijnes represent control 
flow, solid lines represent data flow. For example, tlie diagram of figure LI represents the top level 
PLAN for events-queue- i nsert as the PBM exclusive ok wlicre the predicate 

(or (null evq) (before? entry (car evq))) 

I 
determines whcilicr Iho function returns tln-ougli a cons, or enters ilie cxpi'ession containing the 
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Fig. 13. 11ic top level PLAN for cvcnts-qucue-insert 
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Fig. 14. The predicate for testing list elements 
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Fig. 15. The PL.AN for inscrtin}; an clement in a list 
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body of the loop. (See figure 12b for die code for events-queue-insert.) There is data flow from tlie 
inputs item and time to the cons function 

(cons time item) 

which produces tlie data value entry that is tested by the predicate above. The diagram contains 
branched control flow to show that there are two possible outcomes of the test. The box at the 
bottom labeled yom preserves the one-in one-out property of compound actions. 

Each compound action has certain allowable components, called roles, lliere is a grammar 
(which I will not present here) that restricts the elements which can fulfill a given role, and also 
determines the number and the types of roles permitted in compound actions. In the figures, tlie role 
a component fulfills is printed on its upper left-hand corner. 



4.2.2 The PLAN for events-queue-insert 

/**^ The PLAN for Gvents-queiie-inseri. is broken up into a conditional tliat dcteriiiines whether the 

loop is to be entered (figure 13), a compound predicate which represents an ordering test (figure 14) 
and a PLAN for the loop which contains the splice-in portion of tlie insertion (figure 15). 

The most interesting part of tlie PLAN is figure 15. This loop is decomposed into a generator, 
which enumerates the elements of the events-queue (evq in die diagram), and a /emima/or which 
controls the execution of the loop body. 

The generator represents the code segment 

(defun events-queue-insert (item time evq) 
(prog (nav/ old entry) 

fsetg nev/ fcdr eyq) X 

(jetg old evq) 
lp\\. 

f setq old new) 

(setq new fcdr new)\ 

(go ip))r 

Generators are composed of an optional initialization and a fcc/j' which is the portion that is executed 
many times. The body can contain an operation, a reeursion and a Join, which 1 explain below. 
^p,^ 11ic sole input to the geticrator is ilic variable named evq. This data passes through the 

if}ifia!izdtion 
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(cdr evq) 

which outputs the data (labeled new). The body of tlie generator receives two inputs, new and old, 
where f^W starts as the unmodified events-queue. The operation of the generator body is the function 
cdr, from the code 

(cdr new) 

above. At each successive iteration, this operation causes new to become successive sublists of the 
events-queue. The data values new and old become the output of the generator, emerging from the 
data join box in the diagram. The join indicates that the output can come from one of two places; it 
can be die input to the generator body (in case tlie generator terminates), shown by the data lines that 
pass straight through the diagram, or it can come from tlie box labeled "R" which stands for a 
recursive instance of the enumerator. The cross over of data, where new becomes old at the next 
iteration, can be seen from the change of labels on the data flow lines at the input ports of tjie R 
segment. 
,4^^^, The terminator for the loop is conceptually executed in parallel with tlie generator. At each 

iteration, the predicate compares entry with the value of new that is obtanied from the top of the body 
portion of the generator segment. If the predicate returns through its right hand branch, control 
passes out of the terminator segment, and iteration of the generator body is stopped as well. 

4.2.3 Feature recognition in cliches 

The algorithm recognizer for events-queue -1 nsert is constmcted as a hierarchy of procedures 
which identify each of the segments in tlie PLAN. This cliche finder operates via an exact match 
paradigm; essentially all of the suiictures present in tlie diagrams are required for a non-header-cell 
insertion to be found. The elements of the insertion that were referred to in the bug report (see page 
18) were identified by a feature extraction process that was applied after events-queue-insert had 
been idendfied as a whole. 

For example, the input to events -queue-insert containing the queue is identified as the 
source of the data flow line that enters the generator portion of the loop in figure 15. The name of 
the proi?,ram variable associated witli tliis input (evq in ihis case) is obtained from an annotation in 
tlu? PLAN. (Waters' analysis system provides the code associated wiih IM.AN segments whcpxver 
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possible.) 

Tiie ileiTi to he inserted is identified from tlgure 13 as the first input to die cons function 
fiilfilling the action role of the PLAN. By tracing this data flow line to its source, die entry can be 
identified as die output of die cons function of the inltiaUzation. (If the entry had been one of the 
inputs of events queue insert, there would not have been an initialization. The source of the 
data flow line would have been a lambda input in the PLAN.) 

The generator in figure 15 exacdy corresponds to the PLAN for die trailing pointer enumeration 
cliche. This cliche is a list enumeration that returns pointers to two successive subsets of a list It 
requires cdr operations in both die initialization and operation roles of the generator, and it demands 
that the data flov/ line which is the second input of the generator body be die input to the 
initialization segment as well. These restrictions ensure that successive elements of the list are 
returned no matter how many times die body is executed. 

Events- queue- insert also contains a splice-in operation which is trivially recognized in figure 
15. The PLAN for a splice-in is shown in figure 16. (It does not correspond to a simple piece of 
f^- code.) This operation is composed of a cons, a cdr and a rpl acd function, where die cons creates 

an augmented list, and the rpl acd attaches it to the end of the immediately preceding portion of the 
list. The PLAN representation for this algoridim requires diat the second input to die cons, and die 
first input to die rpl acd function start as a single data path. This path must be split by a cdr 
operation just prior to die cons and rpl acd statements Involved. In figure 15, die cons and rpl acd 
operations are evident, while die role of the cdr function is fulfilled by die cdr in the initialization 
and the cdr in the body of the traiUag pointer enumeration. 

4.3 Extensions 

The generality of the cliche finders could be extended by employing more powerful recognition 
techniques. The existing version of the system can use an exact match paradigm only because it deals 
with algoridims that are simple enough to be represented by a single canonical PLAN. As the size of 
the algorithm increases, the variability associated with its different implementations begins to show 
up in the PLAN, and the exact match paradigm eventually fails. For the recognition tasks involved in 
the scenario, this approach has been successful However, it has not been thoroughly tested. The 
cliche finder currently conicuns two algorillim recognizers; one for the membership test and one for 



/^^ 



Hxccnsions 



-45 



Section 4.3 



/^. 



Fig. 16. Tlie PLAN for the splice-in operation 
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the non-hcadcr-ccll insertion function used in the scenario. 

My original intention was to write the algorithm recognizers as a composition of feature detectors 
for smaller cliches. The hope was that Uiis more hierarchical design could be scaled up to identify 
larger functions. However, die logical analysis underlying PI.ANs actually docs a poor job of 
locaH/.ing some cliches. Fur exatnple, die splice-in function in figure 15 is spread across 4 different 
segment boundaries. T'he result was that a considerable amount of search was involved in finding 
such cliches. (This problem was the motivation for extracting features from events-queue- insert 
after die program was recogni/.ed as a whole, it turned out to be easier to identify the more complex 
entity first, and then pull out die meaningful sub-cliches.) 

The process of recognizing an algoridim from its pans also has tlie problem that die interfiice 
between the sub-cliches in a PLAN can be complex, ['or example, die trailing pointer enumeration 
and the splice-in operation wiUiin evRnts-queue- insert share subsiructure. In t)rder U) ci:»rrolate 
chose overlapping parts, more sophisticated data rcprcsciuations have U) be involved. Rich [Rich 
lOMOj develops a tt)ol called overlays in his thesis which address this issue. 
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A generalized pattern matching facility for performing PLAN recognition would be the method 
of choice for identifying cliches. The creation of such a facility is a very difficult task, and it involves 
both computational and representational issues that are unsolved. It is well beyond the scope of ttie 
cliche finder as I envisioned it. Brotsky [to appear] is working on this topic for his Master's degree. 
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5. The sniffer system 

The sniffer system provides a mechanism for representing knowledge about errors in code. It is 
organized as a collection of independent experts (called sniffers ) which localize the information 
required to identify specific bugs. Each expert can use the facilities of both the time rover and the 
cliche finder to recognize its particular error. For example, the cons bug sniffer (which produced the 
bug report in tlie scenario) used the cliche finder to determine that events-queue-insert was a 
non-header-cell insertion, and it employed the time rover to identify the control paths taken during 
that function's evaluation, hi addition, the cons bug sniffer found the values for data objects by 
causing the time rover to reexecutc portions of die test program's code. 

The sniffer system currendy uses a simple control stmcture to chose the experts relevant to 
particular problems. It runs all of its sniffers all of die time, and each expert is designed to fail 
quickly when it does not apply to the task at hand. In tlie current version of Sniffer, there is exactly 
one expert (the one used in the scenario), altliough a number of extensions are planned. (See the 
secdon on future work for a discussion.) When the experts begin to share infonnadon, a more 
complex control strategy will be required. 

5.1 A geiieric bug detector 

Each expert in the sniffer system contains three basic parts; a collection of triggers which 
determine if the expert is relevant, a body, which recognizes an error, and a template report tiiat 
produces output which describes the bug. 

The triggers are filter functions wliich detcnnine if a given expert should be tried. If diey 
succeed, die body of the expert is executed, and if the body succeeds, die template output is 
displayed. Triggers are computationally inexpensive tests that fail if some essential feature is not 
present. For example, die trigger for the sniffer used in the scenario was the cliche finder responsible 
for identifying events-queue-insert. (Odier cheaper triggers could also be employed. For 
example, the presence of keywords such as "member" or "insert" inside of function names within the 
user's code could cause specific bug experts to be applied.) 

Tlie body of an expert contains tests wliich recognize a particular error. These tests are not 
restricted in any way; the body can use bf){h the lime nncr and the cliche finder to detect die critical 
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features which "implement" a given bug. For example, the body of the sniffer used in the scenario 
examined the control flow in events- queue- insert, the PLAN for Uiat function and specific 
values of the events-queue. It also examined die PLAN and execution sequence in tlie caller of 
events-queue-insert, which was the function metastasize. Once llie bug has been recognized, 
the body determines some additional context elements (such as die text for tlie programs involved, as 
opposed to dieir PLANs) and sends die results to the template report. 

The template report mechanism produces the most comprehensive description of the bug which 
the sniffers can provide. Each template contains two sections; a summary of die error, and an 
analysis of the events surrounding the specific occurrence of the bug. The summary is a piece of 
canned text that uses a vocabulary which is justified by the examinations the experts perform. All die 
cliches it mendons are recognized by the sniffer body in the process of identifying the error. The 
analysis section explains how the test program acted on specific data values to produce tlie 
manifestation of the error observed. It provides tlie input and output values of procedures, and 
displays interesting intermediate results diat weie internal to specific cliches. 
f^' The sniffer system employs template reports in order to avoid die need for natural language 

generation fricilities- Each template contains canned text interspersed with slots that are filled with 
data provided by the sniffers. In die output shown in the scenario (see page 18), die lower case 
information was produced by die template, and the data in upper case were the parairieters which 
filled in the holes. 

5.2 The Cons Bug Sniffer 

In the scenario, the sniffer system was invoked by die expression 

(get_expert_help '(events-queue-member events-queue new-cell) 
(focus-time) 
(end focus-time)) 

where the region enclosed by the two times encompassed a single execution of 
events-qucue-insert. (The function get-expert-help nins all the bug experts, taking the 
union of dicir results.) llic sniffer which produced the output shown on page 18 was called die com 
hug sniffer for sorted lists. 

I'hc c»ili(:.:i! acticMis ofthe cons bug snin\:r are sumniati/cd in figure 17. The trigger of tlic expert 
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was the cliche finder for identifying a non-header-ccll insertion. It was apphed to die PLAN for 
events-queue- insert. When this ran successfully, the sniffer body extracted the following 
features from that PLAN; the ordering predicate test,^ the header-cell-insertion (which corresponds 
to the PLAN in figure 15), the splice-in operation, the cons function which was evaluated on exit 
from events-queue- insert, and die variables or code fragments which idendfied the item to be 
inserted and the queue. These features were identified by simple operation on PLANs. For example, 
the cons return fills an action role of die exclusive-or shown in figure 13. (See the discussion in tJie 
section on feature recognidon in cliches.) 

Fig. 17. The Cons Bug sniffer. 

The cons bug sniffer is invoked ¥/ith a user^supplied predicate describing the error, and a region of 
tlie test program's execution which specifies a particular piece of code. The following tests define the 
presence of die cons bug. 



Triggers 



* The PLAN for region must exacdy match the PLAN for a 
non-header-celMnsertion 



Body 



* The header-cell 'insertion, and the splicc-in portion of region must 
not he executed between the two times. 

* The ordering predicate test was executed. 

* The inserdon function returned by consing the item to be inserted 
onto the list. 

* The value returned by rjie insertion funcdon was not used (in die 
environment of its caller) to side-effect the list. 



^^, \. 'I h-: ord'jriiii; pfcdicatc was idi'iuified by the presence ofaii ardedns ic-4 of the form « a b) or (> a b). Ilie enclosing usage 

of iliat ;w.;dic;ile was inp.ored. e.^^ , n b). nnd Ou)! i< a b)). etc.. were jiiJi'cd Ujiih.ilenL 
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With tliese features in hand, the cons bug sniffer proceeded to identify the critical events 
associated with its bug. These tests were principally involved with determining the control path 
actually taken tlirough the events-queue-insert. First, tlie sniffer determined that the 
header-cell-insertion in tlie PLAN was nol executed. This was accomplished by finding tlie code 
attached to tlie PLAN for tliat cliche, and submitting a request to tlie time rover (which was expected 
to fail) of the form 

(future-when '(during code) focus-time (end focus-time)) 

This expression translates to the statement, "was tliis code executed between tliese two times". (The 
last two arguments are optional parameters which identify a region of the execution trace to 
examine.) In the case of tl"ic non-hcader-cell-insertion, diere was no single piece of code associated 
v/ith tlie entire cliche. The search was conducted for a piece of code attached to an internal segment 
of the PLAN which had to have been executed if the insertion occurred. The cons bug sniffer 
perfonned similar tests to establish tliat tlie ordering predicate was executed and Uiat execution led to 
tlie cons return described above. 

The final criteria for tlie cons bug requires diat the list returned by the insertion fimction cannot 
be used to side effect the queue. This can be established in several ways. The most direct method is 
to use tiic time rover to examine the queue for side-effects. The cons bug sniffer accomplishes this 
by running the expression 

(unmodified* (@ focus-time events-queue) 

(§ (end focus-time) events-queue)) 

If tlie predicate returns tiiie, then the list held by the variable events-queue was not side-effected 
between the two times. 

In the example of the cons bug shown in the scenario, the sniffer discovers the same fact (in a 
more informative way) by examining the PLAN for the function metastasize. This PLAN shows 
that tliere is no data flow coming from ihc return value of the insertion function. This can be seen in 
the body of met as tas i ze (see page 18) by the fact that the code fragment 

(events-queue-insert new-cell (+ div-time 2) events-queue) 
(events-queue-insert key-cell (+ div~tima 2) events-queue) 

cci^'osts of two independent s-cxpressions, When the cons bug sniffer defected ihis information, it 
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produced die bug report statement 

the function (defun metastasize ...) ignores the value returned by 
events-queue-insert. 

Once the cons bug sniffer established diat die bug Vv^as present, it determined a number of 
specific data values to be used as context in the bug report. This information included the code for 
events-queue-insert and metastasize (obtained from an annotation on tlie top level segments 
in their PLANs), die value of the variable containing die events-queue within the insertion routine, 
and die value returned by events-queue-insert. Each of these data values was obtained by using 
the time rover to reexecute portions of the code.^ For example, the value returned by 
events-queue- insert was duplicated by the request 

(Q (futune-when '(during '(cons entry evq)) focus-time) 
' (cons entry evq)) 

This expression searches forward from focus-time to die moment when (cons entry evq) was 
being evaluated, and executes that same expression in an alternate dmc track branching off from that 
moment. The results are necessarily equivalent. 

The predicate, (events-queue-member events-queue new-cell), which die user supplied to 
describe the bug, was not employed as a specification for the error. It was used only to provide 
contextual information for the bug report. (Specifically, if die PLAN for die predicate included a 
membership test, it v/as used to extract die variable name for die object which the membership test 
searched for. The user presumably wanted that object to be stored in the queue. This was die 
variable new-cell in the scenario.) In this particular case, a problem description was not required 
because the cons bug is essentially a violation of rational fonn in die domain of programming. It is 
rare to invoke any function for its side-effects when it docs not always produce diemi, but in the case 
of a routine known to be a list insertion, die expectations associated with its use are much stronger. 

There is an issue here relating to the breaddi of knowledge in die bug experts. When the sniffers 
are attempting to recognize die code associated vvith an error, diey know precisely what they are 
looking for. In this environment, an exact match paradigm is a reasonable method to employ. 



1. llic execution trace contains {he values: relumed b}/ all expressions execiiled by the test program, but they are not 
/*^ necessarily easy lo identify as return values, llie time rover records a!i side-effect events, but a given function am return any 

cell- id in the trace. 
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However, there are no constraints on the expression which tJie user types in to describe the bug. {t 
could be a specific and useful definition of the error, or it might revolve on a fact in the application 
domain for the test program which would make little sense to tlie bug experts. This points out that 
tlie analysis applied to tlie user's predicate needs to be flexible. If tlie predicate cannot be totally 
recognized, then it can be parsed for features which could be used to select relevant bug experts. 
Alternatively, if the sniffer system grows considerably larger, the user's predicate could flmction as a 
source of hints for the direction which further analysis should pursue. 
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6. Future work 

The top level goal of this research was to develop a system that understands (some) bugs. Sniffer 
has accomplished a portion of this task by demonstrating a deep understanding of one bug with what 
appears to be a general mechanism. The next step of the project involves proving that generality, and 
testing tlie power of Sniffer's expert system approach. To do this, I intend to expand the sniffer 
system, by implementing a number of additional bug experts. These experts will cover a range of bug 
types, some related to the cons bug, and some concerned with more abstract programming cliches. 

For example, a list data abstraction can contain a number of bugs which involve violated 
expectations about die maintenance of objects. If the lookup function believes tliere is a header cell, 
but tlie inseri fimction does not, dien any data item at die beginning of the list becomes invisible with 
respect to the lookup operation. If the insertion algoritlim implements a bag which can contain 
multiple copies of an item, but die deleie function removes diem all, the user will perceive that 
inserted data spontaneously disappears. There are a number of similar errors of tliis type. 

Another class of bugs detectors would deal with tlie interactions involving shared data. These 
bugs are particularly confusing to programmers (as diey involve dynamic list structure and subde 
interactions in code) but are ideal candidates for Sniffer because of the facilities provided by die time 
rover. A typical symptom of unexpected sharing is die unexplained appearance or destiuction of 
data objects. A problem that comes from die absence of shared data is diat expected side effects do 
not occur. Alternatively, items which are expected to be eq are not judged to be equivalent. 

I suspect that there is also a set of bugs involving violations of rational fonu in the programming 
domain. These bugs could be catalogued by examining the expectations associated with specific 
programming cliches. The cons bug in die scenario is an example. Except for bizarre situations, any 
time a list insertion returns v/ithout side-effecting its input, something is likel}' to be wrong. (This is 
especially tioie when die user decides to complain about it.) In the case of a queue and process cliche 
(this corresponds to die control structure of prospet), it is reasonable to expect tJiat the results of 
processing an item arc inserted back into die queue. The bug in die scenario also relates to this 
cliche. 

The power of the bug recognizers can also be demonstrated by expanding die amount of bug 
localization each sniffer perfi)rrns. For example, die sniffer system could have been invoked at an 
earlier point in the scenario, when tlic bug had only been traced to the function metastasize. The 
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cons bug sniffer would then identify the presence of an Insertion within motastasize and proceed 
to recognize tJie bug from there. There is also no reason why a sniffer cannot localize a bug to section 
of code and a region of execution tliat are completely different frotn tlie ones whicli the user initially 
provides. The support routines are present, what it requires is a more flexible metliod for directing a 
given sniffer. Each bug detector could presumably function by extracting hints ft'om the user's error 
description, or directly from tlie user if that input was required. 

Once a number of bug detectors have been written, I expect the research to proceed in the 
direction of fonnalizing the knowledge v/hich was gained. At that point, it would become 
appropriate to rewrite tlie sniffer system to involve sharing of information between experts, a 
taxonomy of bugs, and perhaps a hierarchical understanding of cliches. Some of these developments 
rely on more powerful recognition techniques v/hich are not yet available, although they are being 
developed at this time. (See [Brotsky, to appear].) One potential outcome of this research is an 
understanding of tlie constraints involved in tlie problem of error recognition, which is a step towards 
a theory of understanding bugs. 
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7. Related work 

To my knowledge, no previous work has had tlie primary goal of generating a deep 
understanding of bugs in programs. The most closely related efforts are Hacker [Sussman 1973] and 
Ruth's thesis entitled " The analysis of algorithm implementations " [Ruth 1973]. (Sec [Lukey 1978] 
for a survey article describing work in this general field.) 

Hacker is a system diat designs and modifies programxS to solve problems in the blocks-world 
domain, It employs an iterative approach. ITie system proposes a possibly buggy solution for a 
problem, ams the code, and analyzes any error which is produced. Hacker dien applies a method for 
modifying tlie code that is believed to correct the error of die type discovered. If tlie new solution 
does not work, die process is repeated. 

Hacker is primarily an effort in learning and automatic programming, as opposed to a thesis 
about debugging. (This is emiphasized by Hacker's complete name, " A Com putational Model of Skill 
Acquisition".) One of ttie system's major developments is that it expHcitly represents knowledge 
about coding. There is no doubt Uiat Hacker demonstrates a deep understanding of the programs it 
writes. It can notice when a program violates one of die subgoals of a blocks^ world task, and it can 
use the infonnadon associated with this error to generate a complex program diat avoids the bug. 
However, die process of bug classification is the least well-defined pordon of die system. 

Hacker gains a considerable amount of its leverage from the use of a toy domain which allows 
only a limited set of well understood operations. For example, each of the primidve blocks-world 
functions has a known purpose, which can be cited in the process of analyzing errors. The bugs 
which Hacker recognizes also involve constraints in this dom.ain. For example, one of die errors 
discussed in Sussman's diesis involves two sub-goal problems which exacdy undo one another's 
effects in the act of building a tower. 

Sniffer applies similar domain constraints to generate its understanding of errors. In Sniffer's 
case however, the expertise lies in the domain of programming, and concerns the implementadons 
and use of programming cliches. As a result of this approach, die system can recognize bugs in 
arbitrary programs, regardless of the tasks they perform. 

Greg Rudi's dissertation describes a system that can recognize implementations for algorithms of 
a given class, and can also recognize buggy versions of those procedures. Hie system is based on a 
grammiar wliich defines a class of programs. It inputs a grammar, and a function which it then 
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attempts to parse using that grammar. If it succeeds, die code is recognized as a member of the set of 
correct programs. Ruth extends the number of programs which can be identified by applying a 
collection of behavior preserving transformations to the code being analyzed. If the transformed 
function can be parsed by the grammar, it is also recognized as correct. Much of tlie system's 
knovvledge concerns tliese rewriting rules. 

In a similar way, Ruth's analyzer can identify errors. It does this by applying corrective 
transformations to the input code and ilien attempting to recognize the resulting routine. If the new 
finiction is within die set defined by the grammar, tlie error is analyzed as tlie inverse of the 
corrective transfoiTnation which was applied. 

The kinds of bugs v/hich Rutli's system can discover have a very syntactic feel. It treats programs 
as textual objects, without any detailed representation for tlieir composition or the purpose of their 
parts. Sniffer, on the other hand, generates its power from an in depth analysis of the building blocks 
invohed. The two programs also take fundamentally different approaches to the task of recognizing 
errors. Ruth's diesis diagnoses bugs as deviations from a predefined norm, whereas Sniffer searches 
r^ for specific error-defining patterns. Sniffer uses this mechanism to represent extensive knowledge 

about particular bugs. 

The programmer's apprentice project at MIT has produced a good deal of work in the domain of 
program understanding. Rich and Shrobe [1976] laid down the basics for die decomposition of Lisp 
programs into purposeful parts. Waters [1978] developed an analyzer which translates programs into 
PLANs. (This thesis relies heavily en the system which Waters implemented.) Rich's dissertation 
[Rich 1980] develops a mathematical foundation for the PLAN representation, and creates a library 
of PLANs for programming cliches. The complexity of die PLANs in this library range from the 
level of a variable interchange to the the queue and process strategy employed by prosper. (The 
library also includes die insertion plan discussed in the scenario.) Rich makes concrete suggesdons for 
the constracdon of a PLAN recognition system whicli a more general version of the cliche finder 
would require. Brotsky [to appear] is working on diis topic as the subject of his Master's diesis. 

There has been some work towards an abstract dieory of bugs in programs [Miller and Goldstein 
1977] wliich goes beyond the domain dependent classifications developed in Hacker. The authors 
develop a planning grammar which can be used to describe programs, where statements in the 
grammar can be refined into runnablc code, llie autluirs then define a semandc error as a violation 
of the problem description, and a syntactic error as a bug in die use of the grammar. This grammar 
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does not have the conceptual richness of the PLAN representations used in the apprentice project, 
and die relation between their bug types and errors in more complicated programs is unclear. 

There has been a considerable amount of work on expert systems (analogous to Sniffer) which 
perform complex tasks. That method of organization is one of die most successful paradigms in AI. 
The unifying characteristics of the systems which use this approach are tliat they rely on a number of 
independent methods for gathering infonnation and they deal with a large number of facts in the 
process of finding solutions. 

The Sinmlation and Evaluation of Chemical Synthesis project (SECS) [Wipke 1969], the Dendral 
project, and much of die w^ork in AT and medicine are in diis class. SECS is an expert in die design of 
organic synlheses. The information relevant to this task includes empirical fticts about reaction 
coriditions and die sensitivities of functional groups, the 3-dimensional shape of the target molecule 
(the one to be synthesized), the composition of the target, and electronic energy levels of both the 
product and the reactants. To coordinate these different sources of infonn.ation, SECS confines a 
great deal of its expertise to a set of productions which examine these facts and determine if a given 
^'^' chemical reaction (applied to a pardcular molecule) will succeed or fail. The system performs at the 

level of a skilled chemist. 

Sniffer also provides a tool for supporting die debugging process. There are two basically 
different approaches to diis task. First, diere are systems diat simplify the process of tracking down 
bugs, and second, there are methods that prevent bugs from happening in the first place. The first 
category includes debugging environments similar to the one implemented on the Lisp Machine, 
which provide a single step evaluator and predicates for examining the data in die execution stack. 
The Ume rover is a straight forward extension of this environment. (Every major programming 
installation provides some support for activity of this kind.) 

Bug prevention methods exist primarily in the domain of software engineering. Many of die 
ideas included under this term relate more to the process of coding than to die stmcture of die code 
which is produced. However, data abstraction techniques [Liskov 1977] are particularly relevant to 
the kinds of errors which Sniffer detects. 

Data abstractions occupy die borderline between program understanding methods and 
programming language techniques, since abstraction mechanisms build the level of vocabulary used 
to discuss a program. Research in verification uses this fact, in that it tends to rely heavily on data 
ahstraciions as a place to attach restrictions"; about the properties (or segments of code. 
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Data abstractions also imply a very strong form of type checking which makes certain kinds of 
errors much harder to coramit. For example, the cons-bug error (which concerns the integrity of an 
object and the division of responsibility for maintaining its properties) can only be committed within 
the confines of a particular abstraction. These kinds of errors can not be totally avoided, but their 
frequency can be diminished by employing these techniques. 
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